home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.20021006-20030409
/
000008_jfathman@aol.com_Tue Oct 8 09:43:48 EDT 2002.msg
< prev
next >
Wrap
Text File
|
2003-04-08
|
2KB
|
49 lines
Article: 13770 of comp.protocols.kermit.misc
Path: newsmaster.cc.columbia.edu!panix!bloom-beacon.mit.edu!newsfeed.stanford.edu!postnews1.google.com!not-for-mail
From: jfathman@aol.com (Jim)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: YModem
Date: 7 Oct 2002 15:53:22 -0700
Organization: http://groups.google.com/
Lines: 30
Message-ID: <6dfb5332.0210071453.495b2fbc@posting.google.com>
References: <6dfb5332.0210051812.463a13dc@posting.google.com> <anpjau$2cp$1@watsol.cc.columbia.edu>
NNTP-Posting-Host: 168.103.194.77
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1034031202 14854 127.0.0.1 (7 Oct 2002 22:53:22 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 7 Oct 2002 22:53:22 GMT
Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:13770
Frank,
Your Telnet tip got me going. Here is some follow-up for the benefit
of future readers.
RFC 854 (Telnet Command Structure) spells out very clearly that Telnet
will 'double' the IAC (255 = 0xFF) byte when it is sent as data. This
is what I was seeing as the extra 0xFF between the YModem packet
header and the start of the data section.
There are a couple of solutions. One (see RFC 856, Telnet Binary
Transmission) is to recognize IAC DO BINARY commands and respond with
IAC WILL BINARY, and to recognize IAC WILL BINARY commands and respond
with IAC DO BINARY.
I tried this with a couple of commercial telnet versions, and it
worked. But a couple of other commercial telnet versions did not send
the IAC DO BINARY or IAC WILL BINARY commands, so it is not a
universal solution.
The second solution, which seems to work universally, is to ignore the
IAC DO BINARY and IAC WILL BINARY commands. The Telnet connection
will then remain in 'not binary' mode with data 0xFFs repeated in the
data stream. The trick then is to detect a sequence of two 0xFFs, and
discard one of them. Works like a champ.
Thanks again for the Telnet tip. It pointed me in the right
direction.
Jim